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callee method is then inlined within the first method. In 
addition, no conditional statements are inserted into the 
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made by a just-in-time compiler, and if the methods are Java 
methods, then a Java just-in-time compiler performs the 
optimization process. If a determination is made to load a 
class that contains a method that overrides the callee 
method, then the calling method is recompiled or patched. 
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doss FigureSA \ 

public int Figure5methodl(booleon bytel, chor chorl, double doublel, short short!) j 
return 0; 

i 

public stotic int Figure5method2(byte byte2, double doubie2, float floot2, Object object2, 
int integer2, long long2) j 
return 0; 

i 

1 FIG. 5A 
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public void boo (SubC s) { 

FIG. 7C s ' ,0 °("> : 



Pseudo-code of method boo() compiled with conventional JIT: 
boo() i 

if (s.foo() is SubC's foo() method) then 
JPJQ QJ^ i nl ' ne co <te ^om SubC's foo() method; 

else 

invoke method s.foo(); 

endif 



FIG. 8B 



Pseudo-code of method bor() optimized with present invention: 
boo() { 

inline code from SubC's foo() method; 

i 



Vector origVec = new Vector( ray.getOriginQ.getXi 

ray.getOriginQ.getYl 
roy.getOrigin().getZ() ); 

FIG. 9A 



public Point getOrigin() j return Origin; } /* in class Roy.javo */ 

public float getXQ j return X; j /♦ in class Point java */ 

public floot getYQ | return Y; I /* in class Point.jovo */ 

public float getZQ } return Z; j /* in class Point.java */ 

FIG. 9B 
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;; Pseudo machine code of statement ray.GetOrigin().getX() generated by conventional JIT compilers 

;; assume rl = instance ray's reference 
lood r2=[rl] 

lood r2=[r2+offseLget0rigin] 
compare r2 == Roy's getOriginQ 



get method toble of ray 

get method block of getOriginQ 



L10: 



if not equal then goto L10 
;; inlined code for Ray's getOriqin 
load r3=[r1 foffseL origin, field] 
goto L20 

;; have to invoke ray,getOrigin() 
sove rl 

call [ r2 + compiled, code, offset] 
lood r3=r1 
restore r1 



L20: 



get origin from instance r1 



sove register r1 on stock 
invoke method getOrigin() 
store return volue to r3 
restore register rl from stock 



1.30: 



;; ot this point, reqister r3 = roy.getOriginQ 
;; next do r3.getX(); 
load r2=[r3] 
load r2=[r2+offseLgetX] 
compare r2 == Point's getXQ 
if not equol then goto L30 
;; inlined code for Point's getXQ 
load r4=[r2+offseLXJield] 
goto 1.40 



get method table of roy.getOriginQ 
get method block of getXQ 



get X from instance r2 



;; hove to invoke r3.getX() 
save r1 

call [r2+compiled_code_offset] 
load r4=r1 
restore r1 



L40: 



sove register r1 on stack 
invoke method getXQ 
store return volue to r3 
restore register rl from stack 



;; at this point, register r4 contains the result 

FIG. 9C 



;;Pseudo machine code of statement ray.GetOriginQ.getXQ generated by the present invention 
;; assume r1 = instance ray's reference 

lood r2=fr1+offseLoriginJield] ; get origin from instance r1 

lood r4=[r2+offseLX_field] ; get X from origin 

;; at this point, register r4 contains the result 

FIG. 9D 
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PROCESS AND SYSTEM FOR JAVA compiler with the ability to improve the performance of a 

VIRTUAL METHOD INVOCATION program by improving the manner in which its methods are 

invoked. It would be particularly advantageous to provide a 
consistent process by which the invocation of virtual meth- 

TECHNICAL FIELD S ods may be optimized. 

The present invention relates generally to an improved SUMMARY OF THE INVENTION 
data processing system and, in particular, to a process and 

system for improved execution performance in a Java virtual ^ P resent * ven ti°a provides a process and system for 

machine. optimizing an invocation of a method. A determination is 

10 made to compile a calling method, and a call to a callee 

DESCRIPTION OF RELATED ART method is detected within the first method. The callee 

method may be a non-final, virtual method, and a determi- 

Since Java is an interpreted language, any programs nation may be made that the callee method has not been 
written in Java, after being converted into Java class files, previously overridden. The callee method is then inlined 
are interpreted by a Java virtual machine (JVM). In order to 15 within the first method. In addition, no conditional state- 
improve performance, many JVMs may compile Java me nts are inserted into the calling method along with the 
classes into platform-specific binary code after they are inlined method. The determination to compile and optimize 
loaded into the JVM. Then, instead of being interpreted, these methods may be made by a just-in-time compiler, and 
Java classes are executed in their compiled native code jf the methods are Java methods, then a Java just-in-time 
format, similar to programs written in other languages, such 20 compiler performs the optimization process. If a determina- 
as C, C++, etc. Such just-in-time (JIT) compilation of Java uon ^ ma d e to load a class that contains a method that 
programs can significantly improve the speed of execution overrides the callee method, then the calling method is 
of Java programs. recompiled or patched. 

A high performance JIT compiler is the key to a high 

performance Java implementation, and one of the most * BRIEF DESCRIPTION OF THE DRAWINGS 

important actions of a high performance JIT compiler is The novel features believed characteristic of the invention 

optimizing method invocation. Because Java is an object- are set f ortn j n me appended claims. The invention itself, 

oriented language, methods and method invocation are however, as well as a preferred mode of use, further objec- 

prevalent in typical Java programs. In Java, there are three tives and advantages thereof, will best be understood by 

kinds of method invocations: (1) static method invocation, 30 reference to the following detailed description of an illus- 

also known as class method invocation; (2) interface method trative embodiment when read in conjunction with the 

invocation; and (3) instance method invocation. An instance accompanying drawings wherein' 

invocation can be a non-virtual method invocation (only for fig. 1 is a pictorial representation depicting a data 

private metoods and object instance imtubzation methods) ^ tem in which ^ nt invention be 

or a virtual method invocation. While static method invo- implemented m accordance wim a preferred embodiment of 

cations and non-virtual instance method invocations are *u/-«™# *• 

. . , ... . , , the present invention; 

easier to optimize due to their static nature, interface method .„ . 

invocations and virtual instance method invocations are the - FI ^ ( 2 15 a blo ? k dla ^ am gating utemal components 

most prevalent in Java. Therefore, improving virtual and of a da,a svstem that ma V implement the present 

interface method invocation is very important for the overall 40 mven lon » 

performance of a JIT compiler. FIG - 3 is a block diagram illustrating the relationship of 

Tt . . t . ujijcia£i software components operating within a computer system 

In Java, a virtual method can be declared final. A final ma ^ment me re sent invention* 

method can not be overridden by any subclass, which a ma ^ emen e P resen mveQ on > 

prevents malicious modification of trusted and verified code FIG * 4 de P lcts a block diagram of a Java virtual machine 

and ensures consistency. Hence, invocations of final meth- 45 ! n acc °rdance with a preferred embodiment of the present 

ods can be more easily optimized by the JIT compiler than invention; 

those of regular virtual methods. FIGS. 5A-5B depict examples of Java source code and its 

An important technique of method invocation optimiza- effects on Java stack frames i 

tion is called inlining. A method is inlined if its code is 50 FIGS. 6A-6C depict a series of classes that explain virtual 

compiled into the calling method's context. Both static and methods and final methods; 

non-virtual methods can be inlined. Final virtual methods, FIGS. 7A-7C depict a series of examples of virtual 

typically though not always, can be inlined. However, a method invocations that explain the differences among vir- 

disadvantage is that regular virtual methods cannot be tual method invocations; 

directly inlined. 55 FIGS. 8A-SB depict a series of examples of pseudocode 

Inlining has important benefits. It dramatically reduces that explain the manner in which the present invention 

the frequency of method invocations, which saves the time inlines virtual methods to improve method invocation per- 

needed to perform those method invocations. More formance; and 

importantly, inlining is synergistic with other code optimi- FIGS. 9A-9D are a series of examples of Java code and 

zations because it makes those optimizations more effective. 60 assembly code that explain the manner in which the present 

Inlining produces much larger blocks of code for the opti- invention inlines virtual methods to improve method invo- 

mizer to work on. This provides a situation that significantly cation performance, 
increases the effectiveness of traditional compiler 

optimizations, thus overcoming a major obstacle to DETAILED DESCRIPTION OF THE 

increased Java programming language performance. 65 PREFERRED EMBODIMENT 

Therefore, in order to improve the performance of certain With reference now to FIG. 1, a pictorial representation 

Java programs, it would be advantageous to provide a JIT depicts a data processing system in which the present 



04/08/2004, EAST Version: 1.4.1 



US 6,507,946 B2 

3 4 

invention may be implemented in accordance with a pre- place of the hardware depicted in FIG. 2. Also, the processes 

ferred embodiment of the present invention. A personal of the present invention may be applied to a multiprocessor 

computer 100 is depicted, which includes a system unit 110, data processing system 

a video display terminal 102 a keyboard 104, storage For k data processing S y Stem 200 if opdonMy 

dev 1C es 108, which may include floppy drives and other s configured ^ a network t not inch £ e sa /, 

^ °,nf aT, f Dd r f?° Vable ^ *!u h~t bus adapter 212, hard disk drive 226, tape drive 228, 

mouse 106. Additional input devices may be included with . rv\ nnxtiia 1 \u . .1. / ; , , ' 

personal computer 100. Personal computer 100 can be ^ d CD-ROM 230. In that case, the computer, to be properly 

implemented using any suitable computer, such as an IBM Called 4 cl,e , nt COmp " ter ' ^t include some type of network 

AptivaTM computer, a product of International Business 10 communication mterface, such as adapter 210, modem 

Machines Corporation, located in Armonk, N.Y. Although 10 222, or the hke As anomer example, data proassmpystem 

the depicted representation shows a personal computer, 20 ? m 7 b f ? system configured to be bootable 

*u 1 j ■ ^ c *i_ * - \- u ■ 1 without relying on some type of network communication 

other embodiments of the present invention may be impic- . . c \ J? 4J , ■ ™ 

mented in other types of data processing systems, such as mterface ' wheU,6r f or ° ot d * ,a Processmg system 200 com- 

network computers, Web based television set top boxes, „ Pnses some type of network commiimcation mterface. As a 

Internet appliances, etc. Computer 100 also preferably " f^f'A * P /^f u ^ ^ I 

includes a graphical user interface that may be implemented ^^^n < M ' hT Wfflch / confi S u ' e 1 d 

by means of system software residing in computer readable ^ ™dA>r flash ROM m order to provide nonvolaUle 

media in operation within computer 100. "enerated dLa 8 ° ^ 

With reference now to FIG. 2, a block diagram illustrates nn \ e , . ^ n . , , 

internal components of a data processing system that may T ° the ' QX ^ les for P race f in S system ^200 include an 

implement the present invention. Data processing system L^T if^ TkT^ ^ < ^ ^ v*™' 

200 is an example of a personal computer, such as computer the ^ or d ™ de ™ eb ' ImerDet informatlon appliances may 

100 in FIG. 1. Data processing system 200 employs a mC W eb " ba f d ^interactive television set-top boxes. The 

peripheral component interconnect (PCI) local bus archilec- „ de P lcted exam P le m ? IG * \ ™ d above-descnbed examples 

tore. Although the depicted example employs a PCI bus, arc not mcant to ^ architectural limitations, 

other bus architectures, such as Micro Channel and ISA, Wlth reference now to FIG, 3, a block diagram illustrates 

may be used. Processor 202 and main memory 204 are the relationship of software components operating within a 

connected to PCI local bus 206 through PCI bridge 208. PCI computer system that may implement the present invention, 

bridge 208 also may include an integrated memory control- 30 Java-based system 300 contains platform specific operating 

ler and cache memory for processor 202. Additional con- s y stem 302 ^ P rovidc s hardware and system support to 

nections to PCI local bus 206 may be made through direct software executing on a specific hardware platform. Java 

component interconnection or through add-in boards. In the Virtual Machinc ( JVM ) 3 °4 is one software application that 

depicted example, local area network (LAN) adapter 210, ma y execute in conjunction with the operating system. JVM 

SCSI host bus adapter 212, and expansion bus interface 214 35 304 P rovides a Java ma-time environment with the ability to 

are connected to PCI local bus 206 by direct component execute Java application or applet 306, which is a program, 

connection. In contrast, audio adapter 216, graphics adapter servlet > or software component written in the Java program- 

218, and audio/video adapter 219 are connected to PCI local mui £ language. The computer system in which JVM 304 

bus 206 by add-in boards inserted into expansion slots. operates may be similar to data processing system 200 or 

Expansion bus interface 214 provides a connection for a 40 computer 100 described above. However, JVM 304 may be 

keyboard and mouse adapter 220, modem 222, and addi- implemented in dedicated hardware on a so-called Java chip, 

tional memory 224. SCSI host bus adapter 212 provides a Java-on-silicon, or Java processor with an embedded pico- 

connection for hard disk drive 226, tape drive 228, and * ava 00X6 • 

CD-ROM drive 230. Typical PCI local bus implementations The present invention provides a process and system for 

will support three or four PCI expansion slots or add-in 45 Java virtual method invocation. Hence, the present invention 

connectors. operates in conjunction with a Java virtual machine yet 

An operating system runs on processor 202 and is used to within the boundaries of a JVM as defined by Java standard 

coordinate and provide control of various components specifications. In order to properly present the present 

within data processing system 200 in FIG. 2. The operating invention, portions of the operation of a Java virtual machine 

system may be a commercially available operating system so according to Java specifications are herein described, 

such as OS/2, which is available from International Business At the center of a Java run-time environment is the JVM, 

Machines Corporation. "OS/2" is a trademark of Interna- which supports all aspects of Java's environment, including 

tional Business Machines Corporation. An object oriented i ts architecture, security features, mobility across networks, 

programming system such as Java may run in conjunction and platform independence. 

with the operating system and provides calls to the operating ss The JVM is a virtual computer, i.e. a computer that is 

system from Java programs or applications executing on specified abstractly. The specification defines certain fea- 

data processing system 200. "Java" is a trademark of Sua tures that every JVM must implement, with some range of 

Microsystems, Inc. Instructions for the operating system, the design choices that may depend upon the platform on which 

object-oriented operating system, and applications or pro- the JVM is designed to execute. For example, all JVMs must 

grams are located on storage devices, such as hard disk drive eo execute Java bytecodes and may use a range of techniques 

226, and may be loaded into main memory 204 for execution to execute the instructions represented by the bytecodes. A 

by processor 202. JVM may be implemented completely in software or some- 

Those of ordinary skill in the art will appreciate that the what in hardware. This flexibility allows different JVMs to 

hardware in FIG. 2 may vary depending on the implemen- be designed for mainframe computers and PDAs, 

tation. Other internal hardware or peripheral devices, such as 65 A JVM must load class files and execute the bytecodes 

flash ROM (or equivalent nonvolatile memory) or optical within them. The Java virtual machine contains a class 

disk drives and the like, may be used in addition to or in loader, which loads class files from an application and the 
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class files from the Java application programming interfaces register (program counter) and Java stack. If the thread is 

(APIs) which are needed by the application. The execution executing a JVM method, the value of the pc register 

engine that executes the bytecodes may vary across plat- indicates the next instruction to execute. If the thread is 

forms and implementations. executing a native method, then the contents of the pc 

The simplest type of software-based execution engine is 5 register are undefined 

a just-in-time compiler. With this type of execution, the Native method sUcks 414 store the state of invocations of 

bytecodes of a method are compneTto^vTma^rS^^ n , at ™ methods : ™ c sta * ° f na ' ive °f h t od "vocations * s 

tto ^TInjlh^^ St0 ^ m a ° ^plementauon-dependent way in native 

r -f— c — It .V • " 4 . — * j "T — , method stacks, registers, or other implementation-dependent 

codefor the mcttj^isthc a cached and reused upon thpxt me Ifl some Ja ^ vjrtual m * chine 

u^^^^^TTES^SS^ tng^n^y^bc ™ implementatioQS> sucn as some IBM developed JVMs, 

implemented in hardware and embedded on a chip so that native mcthod 4U and Java stacks 416 arc combincd 

the Java bytecodes are executed natively. JVMs usually Method flrea ^ dass data ^ fa ^ 

interpret bytecodes, but JVMs may also use other contains ^ instantiated objects . ^ JVM specification 

techniques, such as just-in-urne compiling, to execute byte- strictly defines data types and operations. Most JVM imple- 

c °des. mentations choose to have one method area and one heap, 

When an application is executed on a JVM that is imple- each of which are shared by all threads running inside the 

men ted in software on a platform-specific operating system, JVM. When the JVM loads a class file, it parses information 

a Java application may interact with the host operating about a type from the binary data contained in the class file, 

system by invoking native methods. A Java run-time envi- It places this type information into the method area. Each 

ronment may have two kinds of methods: Java and native. 20 umc a c L ass instance or array is created, the memory for the 

A Java method is written in the Java language, compiled to new ob J ect » allocated from heap 422. JVM 400 includes an 

bytecodes, and stored in class files. A native method is instruction that allocates memory space within the memory 

written in Java or some other language and compiled to the for hea P u 422 u but Eludes no instruction for freeing that 

native machine code of a particular processor. Native meth- ^ace withm the memory. M^ry^a^gemen^^th^ 

ods are stored in a dynamically linked library whose exact 25 dcpi ?i^^^^ 

c . . ., J . c J 7 memorv^allocate^^to~heap_4203^eTiiory^management?424? 

form is platform specific. may_include~ a- gar^ge-colleJPiS^ 

With reference now to FIG. 4, a block diagram of a Java r&laimfrmemorv used £y T ^ject§£^ 
virtual machine is depicted in accordance with a preferred JHBw an^^licatiori. Additionally,^ garbage cojlptor/ 
embodiment of the present invention. Java virtual machine 3Q ^sS^ay^nfcve* objects to' reduce ^p^grnentation"!*/"^ 
(JVM) 400 includes a class loader subsystem 402, which is ^itli^feTence examples of Java 
a mechanism for loading types, such as classes and source code and its effects on Java stack frames are pro- 
interfaces, given fully qualified names. JVM 400 also con- vided. FIG. 5A provides examples of Java programming 
tains runtime data areas 404, execution engine 406, native language source code statements for an instance method, 
method interface 408, and memory management 424. 35 also known as a virtual method, and a class method, also 
Execution engine 406 is a mechanism for executing instruc- known as a static method. FIG. 5B depicts the state of a local 
tions contained in the methods of classes loaded by class variables section of a stack frame. 

loader subsystem 402. Execution engine 406 may be, for The local variables section contains a method's param- 

example, Java interpreter 412 or just-in-time compiler 410. eters and local variables. Compilers place the parameters 

Native method interface 408 allows access to resources in 4Q into the local variable array first, in the order in which they 

the underlying operating system. Native method interface are declared. FIG. 5B shows the local variables section for 

408 may be, for example, a Java native interface. the two methods shown in FIG. 5A. 

Runtime data areas 404 contain native method stacks 414, FIG. 5B shows that the first parameter in the local 

Java stacks 416, PC registers 418, method area 420, and variables section for an instance method "Figure5methodl( 

heap 422. These different data areas represent the organiza- 45 )" is of type "reference", even though no such parameter 

tion of memory needed by JVM 400 to execute a program. appears in the source code. This reference is the hidden 

Java stacks 416 are used to store the state of Java method "this" passed to every instance method. Instance methods 

invocations. When a new thread is launched, the JVM use mis reference to access the instance data of the object 

creates a new Java stack for the thread. The JVM performs upon which they were invoked. As shown for the local 

only two operations directly on Java stacks: it pushes and 50 variables for a class method "Figure5method2( )", class 

pops frames. A thread's Java stack stores the state of Java methods do not receive a hidden "this". Class methods are 

method invocations for the thread. The state of a Java not invoked on objects. A class's instance variables cannot 

method invocation includes its local variables, the param- be accessed from a class method because no instance is 

eters with which it was invoked, its return value, if any, and associated with the method invocation, 

intermediate calculations. Java stacks are composed of stack 55 Data types "byte", "short", "char", and "boolean" in the 

frames. A stack frame contains the state of a single Java source code of FIG. 5 A have data type "int" in the local 

method invocation. When a thread invokes a method, the variables and operand portions of the stack. Each is manipu- 

JVM pushes a new frame onto the Java stack of the thread. lated as an "int" while on the stack frame and then converted 

When the method completes, the JVM pops the frame for back into the proper type when stored in the heap or method 

that method and discards it. A JVM does not have any 60 area. 

registers for holding intermediate values; any Java instruc- All objects are passed by reference, such as "Object 

tion that requires or produces an intermediate value uses the Object2" that is passed as a reference to 

stack for holding the intermediate values. In this manner, the "Figure5method2( )". In Java, all objects are passed by 

Java instruction set is well-defined for a variety of platform reference. Therefore, only object references appear on the 

architectures. 6S stack. 

PC registers 418 are used to indicate the next instruction During method invocation, the difference between class 

to be executed. Each instantiated thread gets its own pc (static) methods and instance (virtual or non- virtual) meth- 



04/08/2004, EAST Version: 1.4.1 



US 6,507,946 B2 



8 



ods is as follows: instance methods require an instance 
before they can be invoked, whereas class methods do not; 
and instance methods need to use dynamic (late) binding at 
actual method invocation time, whereas all class methods 
use static (early) binding at method name resolution time. 
When a class method is invoked, its class name needs to be 
explicitly specified, which can be resolved and bound at JIT 
compile-time. When a virtual instance method is invoked, 
the actual method is selected based on the actual class of the 
object, which may be known only at run-time. 

References to methods are initially symbolic. All invoke 
instructions refer to a constant pool entry that initially 
contains a symbolic reference. When the JVM encounters an 
invoke instruction, if the symbolic reference has not yet been 
resolved, the JVM resolves it as part of the execution of the 
invoke instruction. 

To resolve a symbolic reference, the JVM locates the 
method being referred to symbolically and replaces the 
symbolic reference with a direct refe^^eJ^^^a^reW 
referenceasii c hj|K ^ p^^ 
rnvjoke^ttie^tetho^m 
agajrin-tne futureV'-^y 

During resolution, the JVM also performs several verifi- 
cation checks. These checks ensure that Java language rules 
are followed and that the invoke instruction can be safely 
executed. First, th^ffiNfeensuresemat^m^symboHclll)* 
referencedsmethodsexists. If it exists, it ensures that the 
current class can legally access the method. For example, if 
the method is private, it must be a member of the current 
class. If any of these checks fail, the JVM throws an 
exception. After the method has been resolved, then the 
JVM is ready to invoke it. As can be seen, method invoca- 
tion may incur significant overhead. 

In the prior art, inlining methods in the caller's context 
(method inlining) is a JIT optimization technique for 
improving the performance of method invocation. Namely, 
bytecodes of the callee methods are copied into the caller's 
context at JIT compilation time. The bytecodes of the caller 
method and the inlined callee method are then compiled into 
native machine code. Therefore, when the caller method is 
executed, the callee method is also executed within the caller 
method when necessary, and the actual method invocation is 
avoided at runtime. However, not all methods can be inlined. 
The JIT compiler imposes a number of limitations, such as 
the restriction that inlined methods need to be static 
methods, non- virtual methods, or final virtual methods. It 
seems intuitive that non-final virtual methods cannot be 
inlined because the method actually invoked is determined 
at run-time by the actual class type of the instance reference 
involved in the method invocation. 

Methods that have been explicitly declared final cannot be 
overridden by any subclass. At JIT compilation time, the JIT 
compiler can determine the actual methods involved in the 
method invocations. Therefore, the JIT compiler can inline 
these methods. 

The present invention improves upon prior art invocation 
processes by assuming that a virtual method, if not overrid- 
den by any class, is a final method until it is explicitly 
overridden. By doing so, the present invention can specu- 
latively inline a regular virtual method. 

With reference now to FIGS. 6A-6C, a series of classes 
explain virtual methods and final methods. FIG. 6A shows 
an example of class SuperA with a virtual method foo( ) 
defined in the class. FIG. 6B shows an example of class 
SubB with a final virtual method foo( ). Since class SubB 
extends class SuperA, i.e. class SubB is a subclass of class 
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SuperA or class SuperA is a super class of class SubB, 
method foo( ) of class SubB overrides method foo( ) of class 
SuperA- 

FIG. 6C shows another example of class SubC with a 
virtual method foo( ). Since class SubC extends class 
SuperA, method foo( ) of class SubC overrides method 
foo( ) of class SuperA. 

With reference now to FIGS. 7A-7C, a series of examples 
of virtual method invocations explain the differences among 
these virtual method invocations. 

FIG. 7A shows pseudocode of a method bar ( ) which 
contains an invocation of a virtual method foo( ) of class 
SuperA, Since method foo( ) of class SuperA is explicitly 
overridden by method foo( ) of either class SubB or class 
SubC, the method invocation in bar ( ) can not be optimized 
by the process of the present invention. 

FIG. 7B shows pseudocode of another method moo( ) 
which contains an invocation of a final virtual method foo( ) 
of class SubB. Since method foo( ) of class SubB is a final 
method, the final method invocation s.foo( ) can be opti- 
mized by prior art JIT compilers. 

FIG. 7C shows pseudocode of another method boo( ) 
which contains an invocation of a virtual method foo( ) of 
class SubC. Assume at JIT compilation time, there is no 
subclass of class SubC which overrides method foo( ). Since 
method foo( ) of class SubC is a virtual method and it is not 
overridden yet, the method invocation s.foo( ) can be 
assumed final, and it can be optimized by the process of the 
30 present invention. 

With reference now to FIGS. 8A-8B, a series of examples 
of pseudocode explain the manner in which the present 
invention inlines virtual methods to improve method invo- 
cation performance. In prior art JIT compilers, invocation of 
method s.foo( ) in FIG. 7C can not be directly inlined 
because it is not bound at JIT compilation time. Instead, it 
can be speculatively inlined, as illustrated by pseudocode 
statements in FIG. 8A. By checking whether s.foo( ) is class 
SubC's foo( ) method, the process ensures that the method 
has not been previously overridden and that the inlining of 
the method will properly execute as expected. 

Note that the approach shown in FIG. 8 A may not be 
particularly efficient for two reasons: (1) the overhead of 
checking for subclasses and overridden methods may be 
significant if foo( ) is a small method, i.e. the checking 
process may require more time than the method foo( ) takes 
to execute; and (2) the "if' statement prevents the optimi- 
zation of the inlined code during optimization of method 
boo( ) because compiler optimization is typically based on 
basic blocks, and the additional branch statement breaks the 
original one block into three or four basic blocks. 

To improve on the speculative inlining shown in FIG. 8A, 
the present invention treats virtual methods that have not yet 
been overridden as regular final methods. Virtual methods in 
Java, if not explicitly declared final, may potentially be 
overridden if subclassed. However, at a given point of time, 
many virtual methods are not overridden in the JVM. For 
such methods, their behavior is the same as those explicitly 
declared final. 

Virtual methods that are treated as final methods may 
participate in many optimizations available to the JIT com- 
piler. In particular, aggressive inlining can be applied to 
these methods. FIG. 8B shows pseudocode statements that 
are optimized with the present invention for method boo( ) 
shown in FIG. 7C. If class SubC is not currently subclassed 
in the JVM and if SubCs foo( ) method satisfies the JIT 
compiler's inlining policies, then method s.foo( ) can be 
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fully inlined into the context of method boo( ) when method 
boo( ) is compiled. Note that no branching is needed around 
SubC's foo( ), as is the case in FIG. 8A. 

However, the JVM and the JIT keep track of dependencies 
/among methods. Each JIT compiled method stores a list of 
f.all the methods which are inlined because they are assumed 
final. The depedency lists can be maintained by either JIT or 
jjVM. When a class is loaded into the JVM at run-time, the 
JVM and JIT find all the methods overridden by newly 
loaded classes and invalidate or update JIT compiled code 
that inlines any newly overridden method. This can be 
achieved by simply searching the dependency lists main- 
tained for the JIT compiled methods. For example, the JIT 
remembers that the compiled code of method boo( ) depends 
on SubC's foo( ) not having been overridden by any sub- 
class. If a subclass of SubC is later loaded into the JVM and 
if foo( ) is redefined in the new class, then the JIT compiled 
code of method boo( ) needs to be updated to reflect the new 
JVM state. Iniffia^sWlHe^o^^^ 
be &discar ^d^and ^^ 

With reference now to FIGS. 9 A-9D, a series of examples 
of Java code and assembly code explain the manner in which 
the present invention inlines virtual methods to improve 
method invocation performance. 

FIG. 9 A shows an example of a Java language statement 
which is found in an industry standard benchmark. The Java 
language statement creates a vector from an origin point 
consisting of a point with an x-coordinate, a y-coordinate, 
and a z-coordinate, where getOrigin( ), getX( ), getY( ), and 
getZ( ) are simple methods, shown as statements in FIG. 9B. 
These types of small methods are encouraged by object- 
oriented languages, such as Java, to help encapsulate data 
structures. None of the four methods shown in FIG. 9B is 
overridden by any subclass in this benchmark. 

In order to understand the cost of executing this code 
pattern, FIG. 9C shows some of the pseudo-assembly lan- 
guage code for part of the Java statement "ray.getOrigin( ). 
getX( )" 

In the example shown in FIG. 9C, 12 instructions are 
needed if both methods are speculatively inlined, i.e. neither 
the path between label 1_10 and 1_20 or the path between 
label 1_30 and 1_40 is taken. Many of these instructions 
are computationally expensive because of the data depen- 
dencies among the instructions. 

FIG. 9D shows some of the pseudo-assembly language 
code for part of the Java statement "ray.getOrigin( ).getX( )" 
after using the process of the present invention. In the 
process of the present invention, methods are assumed to be 
final methods until overridden. In the example discussed 
above, i.e. the Java statement "ray.getOrigin( ).getX( 
both the methods getOrigin( ) and getX( ) are considered 
final methods. (In fact, these methods are not overridden in 
the actual implementation of the benchmark.) Instructions in 
FIG. 9D can be generated if both methods getOrigin( ) and 
getX( ) are inlined and copied into the caller's context. 

It should be noted that only two instructions are necessary 
to complete the same task as in FIG. 9C and that further 
optimization of the caller side is possible because of the 
simple code pattern. Also note that as a result of the process 
of the present invention being applied on the benchmark 
code, the time to run the benchmark test was significantly 
reduced. 

Alternatively, the present invention may reserve this kind 
of^aj^tirmzatk^^ 

ve^yj^uentfyrantfrn^ 65 

Any-reconupilation^cost^canrb^r 

numbetofcmethods-are^iighly^^timizedv 
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e advantages of the present invention should be appar- 
ent in light of the detailed description provided above. By 
considering a non-final, virtual method as a final virtual 
|method, the method may be inlined until overridden. The 
j/processing overhead for invoking the method is then elimi- 
[/hated. Although the JVM or JIT may recompile or patch the 
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calling method once it is overridden, the overall perfor- 
mance of the code is increased. If the method is seldom 
1 overridden, then the performance decrease from recompiling 
the calling method is outweighed by the performance 
increase gained by repeatedly executing the code of the 
galled method without invocation overhead. 

A primary benefit of object-oriented programming is that 
it can increase development productivity by providing pow- 
erful language mechanisms for software reuse. In practice, 
such reusability is rarely attained. Extensive use of these 
mechanisms can significantly reduce performance, which 
leads programmers to use them sparingly. Many program- 
mers using the Java programming language avoid using 
fully "virtual" methods and write larger methods, because 
they believe that every virtual method invocation entails a 
significant performance penalty. Fine-grain use of "virtual" 
methods (i.e. methods that are not "static" or "final" in the 
Java programming language) is extremely important to the 
construction of highly reusable classes, because each such 
method acts as a "hook" that allows new subclasses to 
modify the behavior of the superclass. However, because 
many methods are never overridden, the present invention 

otherwise^ 

A significant advantage of the approach of the present 
invention is that it should fit very well in a server environ- 
ment where classes are loaded initially, and new classes are 
seldom loaded thereafter. In this case, the JVM and the JIT 
cOmpilersljejg^ei&stabl^ 
the.y^remain.sUbleJor_the^durafo 

It is important to note that while the present invention has 
been described in the context of a fully functioning data 
processing system, those of ordinary skill in the art will 
appreciate that the processes of the present invention are 
capable of being distributed in the form of a computer 
readable medium of instructions and a variety of forms, and 
that the present invention applies equally regardless of the 
particular type of signal bearing media actually used to carry 
out the distribution. Examples of computer readable media 
include recordable-type media such as floppy disks, a hard 
disk drive, RAM, CD-ROMs, and transmission-type media 
such as digital and analog communications links. 

The description of the present invention has been pre- 
sented for purposes of illustration and description but is not 
intended to be exhaustive or limited to the invention in the 
form disclosed. Many modifications and variations will be 
apparent to those of ordinary skill in the art. The embodi- 
ment was chosen and described in order to best explain the 
principles of the invention and the practical application, and 
to enable others of ordinary skill in the art to understand the 
invention for various embodiments with various modifica- 
tions as are suited to the particular use contemplated. 

What is claimed is: 

1. A process for optimizing an invocation of a method, the 
process comprising the computer-implemented steps of: 
in response to a determination to compile a first method, 

detecting an invocation of a second method by the first 

method; 

inlining the second method in the first method without a 
conditional statement in the first method for conditional 
execution of the inlined second method; and 
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in response to a determination to load a class comprising 
a third method that overrides the second method, per- 
forming one of patching the first method and recom- 
piling the first method, wherein the first method con- 
tains the second method inlined without a conditional 5 
statement. 

2. The process of claim 1 wherein the second method is 
a non-final, virtual method. 

3. The process of claim 1 further comprising: 
determining that the second method has not been previ- 1° 

ously overridden. 

4. A process for optimizing an invocation of a method, the 
process comprising the computer-implemented steps of: 

in response to a determination to compile a first method, 
detecting a call to a second method within the first 15 
method, wherein the second method is a non-final, 
virtual method; 

inlining the second method within the first method with- 
out a conditional statement in the first method for M 
conditional execution of the inlined second method; 
and in response to a determination to load a class 
comprising a third method that overrides the second 
method, performing one of patching the first method 
and recompiling the first method, wherein the first 25 
method contains the second method inlined without a 
conditional statement. 

5. The process of claim 4 wherein the second method is 
unconditionally inlined within the first method. 

6. The process of claim 4, further comprising: 3Q 
just-in-time compiling the first method with the inlined 

second method. 
1. The process of claim 4 wherein the first method and the 
second method are Java methods. 

8. The process of claim 4 further comprising: 35 
determining that the second method has not been previ- 
ously overridden. 

9. The process of claim 4 further comprising: 
maintaining a list of dependencies among methods for 

updating compiled methods that contain inlined meth- 40 
ods that may be overridden. 

10. A data processing system for optimizing an invocation 
of a method, the data processing system comprising: 

detecting means for detecting, in response to a determi- 
nation to compile a first method, a call to a second 45 
method within the first method, wherein the second 
method is a non-final, virtual method; 

inlining means for inlining the second method within the 
first method without a conditional statement in the first 5Q 
method for conditional execution of the inlined second 
method; and 
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at least one of patching means for patching, in response to 
a determination to load a class comprising a third 
method that overrides the second method, the first 
method and recompiling means for recompiling, in 
response to a determination to load a class comprising 
a third method that overrides the second method, the 
first method, wherein the first method contains the 
second method inlined without a conditional statement. 
U. The data processing system of claim 10 wherein the 

second method is unconditionally inlined within the first 

method. 

12. The data processing system of claim 10 further 
comprising: 

compiling means for just-in-time compiling the first 
method with the inlined second method. 

13. The data processing system of claim 10 wherein the 
first method and the second method are Java methods. 

14. The data processing system of claim 10 further 
comprising: 

determining means for determining that the second 
method has not been previously overridden. 

15. The data processing system of claim 10 further 
comprising: 

maintaining means for maintaining a list of dependencies 
among methods for updating compiled methods that 
contain inlined methods that may be overridden. 

16. A computer program product in a computer-readable 
medium for use in a data processing system for optimizing 
an invocation of a method, the computer program product 
comprising: 

instructions for detecting, in response to a determination 
to compile a first method, a call to a second method 
within the first method, wherein the second method is 
a non-final, virtual method; 

instructions for inlining the second method within the first 
method without a conditional statement in the first 
method for conditional execution of the inlined second 
method; and 

instructions for performing one of patching the first 
method and recompiling the first method, in response to 
a determination to load a class comprising a third 
method that overrides the second method, wherein the 
first method contains the second method inlined with- 
out a conditional statement. 

17. The computer program product of claim 16 further 
comprising: 

instructions for determining that the second method has 
not been previously overridden. 
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